[レポート] Rancher Meetup Tokyo #18(モニタリングについて語ろう会) #rancherjp

こんにちは　園部です。

今回は、3月19日に開催されました Rancher Meetup Tokyo #18(モニタリングについて語ろう会) へ参加させていただいたレポートとなります。

Rancherとは？

Rancher は OSS と商用版で提供されるコンテナー環境構築・運用プラットフォームです。 Rancher の特徴は、Kubernetes コンテナオーケストレータ自体もデプロイし、その機能を利用した 効率的なコンテナインフラの構築・管理運用が可能なことです。 また、Active Directory 連携や監査ログ機能などにより本格的なエンタープライズ向けプラットフォームとして世界で導入実績を重ねています。 （引用：イベントサイト）

イベント開催概要

Kubernetesについて盛り上がりはどんどん増しつつあります。 米国ではKubernetesのスキルを持っていることが2019年時点では、もっとも転職に有利に働くといった調査結果もあり (Kuberenetesのスキルは、いま飛び抜けて米国の転職で有利。米Dice＆米Indeed)、 Kuberenetesの人気はますます高まりつつあります。

しかし、本番運用まで含めるとKubernetesのスキルだけではくその周辺スキルも必要になってきます。 今回はその中から特に重要となる"監視・モニタリング"に焦点を絞って解説したいと思います。 （引用：イベントサイト）

Monitoring of Rancher（@cyberblack28 ）

自己紹介

• コンテナベースオーケストレーション の著者
• 3つのコミュニティ運営（#rancherjp, #kujiraya, #deepcn）
• Rancher ってどんなもの？連載中（Think IT）

1. Basic Monitoring

• ClusterやNodeなどのダッシュボードが提供

2. Alerts&Notifiers

• 連携・通知先の設定するだけで利用が可能
• 連携先として、Slack, Email, Webhook などに対応
• コンテナに関するアラートとして、デフォルトで、etcd, kube componetns, event, node にも対応予定（v2.2.0-rc6）
• Memoryは、デフォルトでは利用不可、Prometheusと連携することで利用可能になる予定（v2.2.0-rc6）
• 他にもメトリクスを追加して、Alert 設定が可能
• Alert は、exepresion がNEWサービス（Prometheus連携）で、GUIから簡単に設定可能

3. Basic Logging

• エンドポイント設定を行うことで、多様なサービス（ElasticSearch, spluck, Kafka, Syslog, Fluentd）との連携が可能

4. Monitoring & Logging Catalog

• 各プロダクトのカタログは用意されている（Grafana,、Prometheus、Datadog、ElasticSearch、Fluentdなど）
• 要件に合わせて、任意のカタログをデプロイしていくのがRancherの良いところ

5. Rancher's New Multi tenant Prometheus support

• Rancher 2.2 系列で、Prometheus がカタログからデプロイ出来るようになるため、簡単に構築が可能
• Webinar で発表
• 構築デモ（資料ベース）

6. Multi-Cluster Apps

• Rancher からマルチクラスター（複数AZ）へデプロイが可能
• AKS、GKS、EKSなどのクラウドでのマルチクラスター管理を統一画面から可能 複数のKubernetesクラスタへアプリをまとめてデプロイ、ローリングアップデートなどの新機能を搭載した「Rancher 2.2」が登場
• 構築デモ（資料ベース）

7. Information

Cloud Native Tokyo #01（4/10）

Cloud Native Tokyo #01

k3s

• 軽量化された k8s
• IoT領域などで活躍期待
• （個人検証では）Rancher での管理も可能 Kubernetesをわずか40MBのシングルバイナリとして軽量かつシンプルにした新ディストリビューション「k3s」登場。Rancher Labsがオープンソースで公開

submariner

• クラスタ間のnode通信 Kubernetesクラスタ間をレイヤ3トンネリングで接続、異なるクラスタ内のノード間通信を容易にする「Submariner」、Rancher Labsがオープンソースで公開

所感

• Rancher 2.2 系の新しいバージョンがリリース予定
• Rancher 自体は、簡単な操作（GUI）で、デプロイや管理が可能
• コンテナ管理から多様な環境（マルチクラウド、マルチクラスター）の管理へ進んでいる印象
• k3s や submariner などユニークなものがある

Sysdig クラウドネイティブ インテリジェンス プラットフォームのご紹介（@takao3）

Sysdigとは？

会社紹介

• 起業者は、Wireshark の共同創作者
• 情報はまず全部集めてしまうという発想が強い
• 昨年、Sysdig Japan 合同会社
• 商用製品とOSSを取り扱っている
• Sysdig Monitor, Sysdig Secure, Sysdig Inspect, Falco など

管理対象をめぐる状況

• コンテナやマイクロサービスによって、どんどん複雑化が促進

Sysdig によるコンテナ管理

（引用：https://sysdig.com/）

• オンプレ版とSaaS版がある
• Sysdig バックエンドに情報（システムコール）を送理、各種サービスを提供

• Sysdig エージェント経由でシステムコールをバックエンドへ収集
• システムコールで収集しているので情報の粒度が細かい

• 各ホストではなくサービス視点で表現

Sysdig Monitor Alert

• Alertのタイプとして以下を提供
• メトリクスベース
• イベントベース
• アノマリベース（時系列での異常検知）
• pod ベース
• テンプレートも用意

Sysdig inspect

• ダッシュボード、分析ツール
• 無料ローカル版もある

Sysdig セキュア

• Sysdig MonitorもSysdig Secure も同じSysdig バックエンドに接続しており、UI や提供サービスが異なる
• システムキャプチャを取得
• システムコールを追うことで詳細な原因の追究が可能
• OS上でのコマンドは全て管理
• Compliance 機能
• 詳細なポリシ設定が可能
• Falco ルールも用意
• CIS ベンチマーク 診断の実行も可能
• コンテナイメージスキャンも可能

トライアル＆チュートリアル

• 2週間利用可能
• 発表者のLinkedin にチュートリアルを用意 Linkedin

所感

• コンテナ環境に対して、詳細なモニタリングが可能
• 情報量が多そうな点でのコストやパフォーマンスに関しての懸念される場合は、事前に自分たちのシステムに置き換えて検討が必要

監視 入門 - マイクロサービス時代における監視設計 - （@songmu）

監視 入門 ~ マイクロサービス時代の監視設計

自己紹介

• はてな チーフ、Mackerel プロダクトマネージャー
• Mackererl サーバ監視[実践]入門 みんなのGo言語 入門 監視(付録C)　の著者

監視とは

監視とテスト

• 奧一穂さんの名言「監視とは継続的なテストである」
• 開発者がテストを書くことも一般化したが、監視はまだまだ専門的と思われている
• モニタリングの重要性の向上（マイクロサービスアーキテクチャ）
• やっていくしかない（みたいなことが書いてある）
• Webサービスへの要求の向上
• リアルタイム性
• 監視からは逃れらない
• 「監視とはシステムに対する高速健康診断」 by 発表者
• 監視のコード化 されているため、アプリケーションエンジニアにも扱える領域
• healthエンドポイントパターン
• 「入門 監視」で命名
• /health にアクセスすることで監視用データをレスポンスさせて内容を監視（JSONとか）
• Health Check Reponse Format for HTTP APIs
• https://github.com/inadarei/rfc-healthcheck
• https://tools.ietf.org/html/draft-inadarei-api-health-check-02
• Open Metrics https://openmetrics.io/
• 標準化が検討されている

開発者と監視

• 「テスト駆動開発は、プログラミング中の不安をコントロールする手法だ」
• テスト駆動開発
• 開発者こそ監視するべき
• アプリケーション開発者でこそわかる監視項目があるはず

マイクロサービス時代における監視設計

• アプリケーションとミドルウェアの境界は曖昧になる
• Four Golden Signals（in SRE Book）
• Latency
• Traffic
• Errors
• Saturation
• Use Method（システム・パフォーマンス本）
• http://www.brendangregg.com/usemethod.html
• 詳解 システム・パフォーマンス
• 内部の状態に着目（ブラックボックス）
• Utilization
• Saturation
• Errors
• RED Method
• Monitoring Microservices
• 外部からの振る舞いに着目（ホワイトボックス）
• Rate
• Errors
• Duration
• USEは内部、REDは外部から視点で、補完しあうもの
• 監視パラダイムの変遷
• チェック監視
• メトリクス監視
• Observability

Mackerel コンテナエージェント

• リリースされたコンテナエージェントの紹介
• サイドカー設計
• マイクロホスト課金
• サービスメッシュ、Prometheusと連携も検討

ケーススタディ

• サーバーレスアーキテクチャによる時系列データベースの構築と監視
• サーバレスアーキテクチャによる時系列データベースの構築と監視
• goroutine リークにリリース前に気づけた話
• 外形監視用のデーモンを書いた話
• バッチジョブの監視
• ISUCON6予選運営の話

所感

• 対象となるシステム環境（アーキテクチャ・コード管理・チーム垣根）の変遷に対して、監視も着実にかわっていることを実感しました。
• 監視設計に関する一般化は重要だと個人的にも思います（システム担当 >>> インフラ担当 >>> 運用担当 ではもう最適な監視は設計できないはず）

Feedback from Cloud Native Deep Dive - みんなのモニタリングお悩み共有（@jacopen）

Cloud Native Deep Dive とは？

• 色々なテーマに対して全員参加型のディスカッション
• 事前にアンケート回答の上で、参加
• 前回、Monitoring をテーマにした内容だったため共有
• 他の開催テーマ：Manifest 管理, Service Mesh, Release Engineering, JKD 総集編
• 正解ではなく、議論を行う場

Monitoring

• Blackbox Monitoring と Whitebox Monitoring を分けて考えよう！
• Black Box vs. White Box Monitoring: What You Need To Know
• みんなの課題
• どんなメトリクスを監視すればいいのか？
• k8s のクラスタ管理者とアプリ開発者への通知切り分け
• ロングタームのメトリクス管理方法・ダウンサンプリング方法
• 外れ値対応
• モニタリングのモニタリング
• そもそもダッシュボードはいつ見る？
• Monitoring 101 は読むべき

Logging

• Logging = 課金
• みんなの課題
• Aggregator運用が辛い
• ログ形式バラバラ問題
• ログとメトリクスの横断的な検索

Alert

• みんなの課題
• 閾値の根拠は？
• 誤検知・過剰なアラートへの対応
• 閾値やアラートレベルの見直しはいつやる？
• 通知先
• オンコール担当は誰か
• オンコール先任者・部門が必要か？
• オンコールローテーション
• 突発的なアラートへの対応による生産性の低下
• アラートルールのコード化はどうやるか？
• 通知すべきメトリクスのベストプラクティスはあるのか？

共通課題

• コード化・自動化
• 対応する人・組織・ロール
• OSSか商用製品かManaged Serviceか？

宣伝

• Cloud Native Deep Dive
• 技術書典6

所感

• 「みんなの課題」ではあるあると共感した方も多かったのではないかと思います。
• LT のため、時間の都合があったようで、ハイライトではありましたが、Cloud Native Deep Dive の濃密さを感じます。
• Monitoring 101 はしっかり読んでおこうと思います。

その他

本編が始まる前に、DirectPoll によるアンケート（参加者のロール、Docker 利用状況、k8s 利用状況）が実施されました。こちらは、面白かったです。 アイスブレイクに最適だと思いました。

また翌日に、EKSでのRancher の記事(Managing Amazon EKS Clusters with Rancher )が掲載されており、タイムリーさを感じました。